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1. Introduction 


DMARC [RFC7489] introduces a mechanism for expressing domain-level 
policies and preferences for message validation, disposition, and 
reporting. The DMARC mechanism, especially when employed with 
restrictive policies, encounters several different types of 
interoperability issues due to third-party message sourcing, messag 
transformation, or rerouting. In particular, DMARC with restrictiv 
policies causes problems for many Mailing Lists. 


At the time of writing this document, the DMARC base specification 
has been published as Informational RFC 7489 [RFC7489] and has seen 
significant deployment within the email community. 


Cases in which email does not flow directly from the author’s 
administrative domain to the recipient’s domain(s) are collectively 
referred to in this document as "indirect email flows". Due to 
existing and increasing adoption of DMARC, the impact of DMARC-base 
email rejection policies on indirect email flows can be significant 
for a select subset of general email traffic. 


Several known causes of interoperability issues are presented, 
followed by a description of components within the Internet Mail 
Architecture [RFC5598] where interoperability issues can arise. 


Finally, known and possible methods for addressing interoperability 
issues are presented. There are often multiple ways to address any 
given interoperability issue. While this document strives to be 
comprehensive in its review, it should not be treated as complete. 
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Note that some practices that are in use at the time of this document 
may or may not be "best practices", especially as future standards 
evolve. 


1.1. Document Conventions 


The notation used in this document for structured fields is taken 
from [RFC5598], Section 1.3. 


The term "notification message" ([RFC5321], Section 4.5.5) is used to 
refer to a message with a null RFC5321.MailFrom. 


The terms "Organizational Domain" and "Authenticated Identifiers" are 
specified in DMARC ([RFC7489], Section 3). 


All words that begin with capital letters take their formal meanings 
from these references. 


2. Causes of Interoperability Issues 


Interoperability issues between DMARC and indirect email flows arise 
when conformance to the DMARC specification leads a receiving 
implementation to apply DMARC-based policy restrictions to messages 
that are both compliant with the architecture as specified in 
[RFC5598] and viewed as legitimate by the intended Recipient. 


Note that domains that assert a "p=none" policy and email messages 
that pass standard DMARC validation do not have any interoperability 
issues. 


Email messages that do not conform to IETF email specifications but 
are considered legitimate by the intended Recipients are not 
discussed in this document. 


The rest of this section describes several conceptual causes of 
interoperability issues. 


2.1. Identifier Alignment 


Note to operators and administrators: The identifiers that are used 
by the Sender Policy Framework (SPF) are technical components of the 
transport process for SMTP. They may or may not, as described below, 
bear a meaningful relationship to the content or source of the 
message itself. This "relationship by proximity" can be a point of 
confusion for non-technical end users, either recipients or senders. 
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DMARC relies on DomainKeys Identified Mail (DKIM) [RFC6376] and SPF 
[RFC7208] to perform message source validation. The DMARC [RFC7489] 
specification refers to source domains that are validated by DKIM or 
SPF as "Authenticated Identifiers". To be used by DMARC, an 
"Authenticated Identifier" must also be related to the domain found 
in the message’s RFC5322.From header field [RFC5322]. This 
relationship between an Authenticated Identifier’s domain and the 
domain of the RFC5322.From is referred to as "Identifier Alignment". 


DMARC allows for Identifier Alignment to be determined in two 
different modes: strict and relaxed. Strict mode requires an exact 
match between the domain of any of the Authenticated Identifiers and 
the message’s RFC5322.From header field [RFC5322]. Relaxed mode 
allows for Identifier Alignment if Authenticated Identifiers and the 
message’s RFC5322.From header field [RFC5322] share the same 
Organizational Domain. In general, DMARC interoperability issues are 
the same for both strict and relaxed alignment, but strict alignment 
constrains the possible solutions because of the more rigorous 
matching requirement. Some of the mitigations described in this 
document only work with the relaxed mode of Identifier Alignment. 


2.1.1. DKIM Identifier (s) 


DKIM provides a cryptographic means for one or more domain 
identifiers to be associated with a particular message. Asa 
standalone technology, DKIM identifiers are not required to be 
related to the source of the message’s content. However, for a DKIM 
identifier to align in DMARC, the signing domain of a valid signature 
must be part of the same Organizational Domain as the domain in the 
RFC5322.From header field [RFC5322]. 


In addition, DKIM allows for the possibility of multiple valid 
signatures. These multiple signatures may be from the same or 
different domains; there are no restrictions within the DKIM 
specification. The DMARC mechanism will process Authenticated 
Identifiers that are based on DKIM signatures until an aligned 
Authenticated Identifier is found (if any). However, operational 
experience has shown that some implementations have difficulty 
processing multiple signatures. Implementations that cannot process 
multiple DKIM signatures may incorrectly flag messages as "not 
passing" (DMARC alignment) and erroneously apply DMARC-based policy 
to otherwise conforming messages. 
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Qed 2% SPF Identifier (s) 


The SPF specification [RFC7208] defines two Authenticated Identifiers 
for each message. These identifiers derive from: 


a. the RFC5321.MailFrom [RFC5321] domain, and 
b. the RFC5321.HELO/.EHLO SMTP domain. 


In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is 
defined to be based on RFC5321.MailFrom unless that value is absent 
(as in the case of notification messages), in which case, the second 
(RFC5321.HELO/.EHLO) identifier value is used. This "fallback" 
definition has occasionally been misunderstood by operators of MTA 
systems since notification messages are often an "automatic" feature 
of MTA software. Some MTA software does not provide the ability to 
apply a DKIM signature to such notification messages. 


See Appendix A for an example treatment of this scenario. 


For the purposes of DMARC validation/alignment, the hybrid 
RFC7208.MAILFROM [RFC7208] identifier’s domain is used if and only if 
it is aligned with the RFC5322.From [RFC5322] domain. The alignment 
of the validated domain is determined based on the DMARC record’s 
"strict" or "relaxed" designation as described above for the DKIM 
identifiers and in [RFC7489]. 


2.1.3. Multiple RFC5322.From Addresses 


[RFC5322] permits only one From header field, but it may contain 


multiple mailboxes. Since this is an extremely rare usage, DMARC 
specifies that the handling of this situation is implementation 
dependent. 


Because the presence of multiple domains can be used by an attacker 
(an attacker could add their domain to the RFC5322.From field, 
provide arbitrary new content, and sign the message), the DMARC 
specification recommends that the strictest policy be applied to such 
messages (Section 6.6.1 of [RFC7489]). 


2.2. Message Forwarding 


Section 3 describes forwarding behavior as it relates to the 
components of the Internet Mail Architecture. 


All forwarding operations involve the retransmission of email. As 


discussed above, in order for SPF to yield an Authenticated 
Identifier that is pertinent to DMARC, the domain of the 
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RFC7208.MAILFROM must be in alignment with the RFC5322.From header 
field. Forwarding introduces specific issues to the availability of 
SPF-based Authenticated Identifiers: 


o If the RFC5321.MailFrom is present and the forwarder maintains the 
original RFC5321.MailFrom, SPF validation will fail unless the 
forwarder is an authorized part of the originator’s email sending 
infrastructure. If the forwarder replaces the RFC5321.MailFrom 
with its own domain, SPF might pass, but Identifier Alignment with 
the RFC5322.From header field will fail. 


o If the RFC5321.MailFrom is empty (as in the case of Delivery 
Status Notifications), the RFC5321.HELO/.EHLO domain of the 
forwarder will likely be in a different Organizational Domain than 
the original RFC5322.From header field’s domain. SPF may pass, 
but Identifier Alignment with the RFC5322.From header field will 
fail. 


In both cases, SPF cannot yield relevant Authenticated Identifiers, 
and DKIM must be relied upon to produce results that are relevant to 
DMARC. 


2.3. Message Modification 


Modification of email content invalidates most DKIM signatures, and 
many message-forwarding systems modify email content. Mailing List 
processors are a common example of such systems, but other forwarding 
systems also make modifications. 


Although DKIM provides a length flag so that content can be appended 
without invalidating the signature, in practice, particularly with 
MIME-encoded [RFC2045] messages, a Mailing List processor will do 
more than simply append content (see Section 5.3 of [RFC5598] for 


details). Furthermore, the length flag is seldom used due to 
security issues (see Section 8.2 of [RFC6376] for additional security 
considerations). Therefore, this method is only mentioned here for 
completeness. 


DKIM describes two canonicalizations for use when preparing the 
header and body for DKIM processing: simple and relaxed. The latter 
is designed to accommodate trivial modifications to whitespace and 
folding that, at least in the header case, generally have no semantic 
Significance. However, the relaxed canonicalization is more 
computationally intensive and may not have been preferred in the 
early deployment of DKIM, leaving some deployments using the less 
forgiving "simple" canonicalization. While the prevalence is 
unknown, there are some DKIM verifiers that have problems evaluating 
relaxed canonicalization correctly. 
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3. Internet Mail Architecture, DMARC, and Indirect Email Flows 
This section describes components within the Internet Mail 
Architecture [RFC5598] where interoperability issues between DMARC 
and indirect email flows can be found. 


3.1. Message Handling System 


Section 4 of [RFC5598] describes six basic components that make up 
the Message Handling System (MHS): 


o Message 


o Message User Agent (MUA) 


o Message Submission Agent (MSA) 
o Message Transfer Agent (MTA) 


o Message Delivery Agent (MDA) 


o Message Store (MS) 


Of these components, MSA, MTA, and MDA are discussed in relation to 
interoperability with DMARC. 


Section 5 of [RFC5598] also defines a Mediator as a hybrid of several 
component types. A Mediator is given special consideration in this 
section due to the unique issues they face when attempting to 
interoperate with DMARC. 


3.1.1. Message Submission Agents 
An MSA accepts messages submitted by a Message User Agent (MUA) and 
enforces the policies of the hosting ADministrative Management Domain 
(ADMD) and the requirements of Internet standards. 
MSAs are split into two sub-components: 
o Author-focused MSA functions (aMSA) 
o MHS-focused MSA functions (hMSA) 
MSA interoperability issues with DMARC begin when an aMSA accepts a 
message where the RFC5322.From header field contains a domain that is 
outside of the ADMD of the MSA. This situation manifests in one of 


several ways, such as when someone uses a mail service with their own 
domain but has failed to properly configure an SPF record or when an 
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MUA attempts to transmit mail as someone else. Examples of the 
latter situation include "forward-to-friend" functionality commonly 
found on news/article websites or "send-as" functionality present on 
some MUAS. 


When an hMSA takes responsibility for transit of a message containing 
a domain in the RFC5322.From header field that is outside of the 
hMSA’s ADMD, the hMSA faces DMARC interoperability issues if the 
domain publishes a DMARC policy of "quarantine" or "reject". These 
issues are marked by the inherent difficulty of establishing 
alignment with the domain present in a message’s RFC5322.From header 
field. Examples of this issue include: 


o Partially open relays - a residential ISP that allows its 
customers to relay non-local domains through its infrastructure. 


o Embedded devices - cable/DSL modems, firewalls, wireless access 
points, and printers that send email using hardcoded domains. 


o Devices that send mail on behalf of a user - scanners, security 
cameras, and alarms that send mail as their owner or a device 
user. 

o Email service providers - ESPs that service customers who are 


using domains that publish a DMARC "reject" policy. 


o Calendaring software - an invited member of an event modifies the 
event, causing the calendaring software to emit an update that 
claims to come from the creator of the event. 


3.1.2. Message Transfer Agents 


MTAs relay a message until the message reaches a destination MDA. 
Some common message-handling strategies break the integrity of DKIM 
Signatures. A restrictive DMARC policy along with a broken DKIM 
signature causes latent interoperability problems to become overt 
problems. 


3.1.2.1. Message Encoding 


An MTA may modify the message encoding, for instance, by converting 
8-bit MIME sections to quoted-printable 7-bit sections. This 
modification is outside the scope of DKIM canonicalization and will 
invalidate DKIM signatures that include message content. 
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An MTA could also re-encode the message without changing the encoding 
type: receiving a MIME-encoded message and producing a semantically 
and semiotically equivalent MIME body that is not identical to the 
original. This is characteristic of systems that use some other 
message representation internally. 


3.1.2.2. Header Standardization 


An MTA may rewrite headers to bring them into compliance with 
existing RFCs. For example, some common MTAs will correct 
comprehensible but non-compliant date formats to compliant ones. 


Header rewriting is outside the scope of DKIM canonicalization and 
will invalidate DKIM signatures. All downstream DMARC processing 
with be unable to utilize DKIM to yield Authenticated Identifiers due 
to header rewriting. 


Providing solutions for issues relating to non-RFC-compliant emails 
is outside the scope of this document. 


3.1.2.3. Content Validation 


An MTA may also implement security-motivated changes to the content 
of email messages, dropping or altering sections of messages, causing 
breakage of DKIM signatures. 


3.1.3. Message Delivery Agents 


The MDA transfers a message from the MHS to a mailbox. Like the MSA, 
the MDA consists of two sub-components: 


o MHS-focused MDA functions (hMDA) 
o Recipient-focused MDA functions (rMDA) 


Both the hMDA and the rMDA can redirect a message to an alternative 
address. DMARC interoperability issues related to redirecting of 
messages are described in Section 3.2. 


Sieve [RFC5228] functionality often lives in the rMDA sub-component 
and can cause DMARC interoperability issues. The Sieve ’addheader’ 
and ’deleteheader’ filtering actions can modify messages and 
invalidate DKIM signatures, removing DKIM-supplied Authenticated 
Identifiers as inputs to the DMARC mechanism. There are also Sieve 
extensions [RFC5703] that modify the body. Sieve alterations may 
only become an issue when the email is reintroduced into the 
transport infrastructure. 


Martin, et al. Informational [Page 10] 


RFC 7960 DMARC Indirect Email Interop Issues September 2016 


3.2. Mediators 


Mediators [RFC5598] forward messages through a re-posting process. 
Mediators share some functionality with basic MTA relaying but have 
greater flexibility in both addressing and content modifications. 


DMARC interoperability issues are common within the context of 
Mediators, which are often used precisely for their ability to modify 
messages. 


The DMARC design does not cope with some Mediator functionality such 
as content modifications that invalidate DKIM signatures and 
RFC5321.MailFrom rewriting to support SPF authentication of re-sent 
mail when the new Recipient receives the message from the Mediator 
rather than the initial organization. 


3.2.1. Alias 


An Alias is a simple re-addressing facility that provides one or more 
new Internet Mail addresses, rather than a single, internal one. A 
message continues through the transfer service for delivery to one or 
more alternative addresses. 


Aliases can be implemented by mailbox-level forwarding (e.g., through 
"dot-forwarding"), Sieve-level forwarding (through the Sieve 
"redirect" action), or other methods. When an Alias preserves 
message content and does not make significant header changes, DKIM 
signatures may remain valid. However, Aliases often extend the 
delivery path outside of the scope covered by the originating ADMD’s 
SPF record(s). 


Examples of Aliasing include: 


o Forwarding email between free email (freemail) providers to try 
different interfaces while maintaining an original email address; 


o Consolidating many email addresses into a single account to 
centralize processing; and 


o Services that provide "activity-based", "role-based", "vanity", or 
"temporary" email addresses such as universities and professional 
associations. For instance, professional or alumni institutions 
may offer their members an Alias for the duration of their 
membership but may not want to deal with the long-term storage of 
emails. 
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In most cases, the aMSA providing Alias services has no 
administrative relationship to the ADMD of the originator or the 
Final Recipient, so solutions to Alias-related DMARC failure should 
not assume such a relationship. 


3.2.2. ReSenders 


ReSenders "splice" a message’s addressing information to connect the 
Author of the original message with the Recipient(s) of the new 
message. The new Recipient sees the message as being from the 
original Author, even if the Mediator adds commentary. 


Without Authenticated Identifiers aligned with the Author’s 
RFC5322.From header field domain, the new Recipient has no way to 
achieve a passing DMARC evaluation. 


Examples of ReSenders include MUA-level forwarding by resending a 
message to a new Recipient or by forwarding a message "inline" toa 
new Recipient (this does not include forwarding a message "as an 
attachment"). An additional example comes in the form of calendaring 
software that allows a meeting attendee (not the meeting organizer) 
to modify the content of an invite generating new invitations that 
claim to be reissued from the meeting organizer. 


3.2.3. Mailing Lists 


A Mailing List receives messages as an explicit addressee and then 


reposts them to a list of subscribed members. The Mailing List 
performs a task that can be viewed as an elaboration of the ReSender 
actions. 


Mailing Lists share the same DMARC interoperability issues as 
ReSenders (Section 3.2.2) and very commonly modify headers or message 
content in ways that will cause DKIM to fail, including: 


O prepending the RFC5322.Subject header field with a tag, to allow 
the Recipient to easily identify the Mailing List within a subject 


line listing; 


o adding a footer to the email body to contain administrative 
instructions; 


o removing some MIME-parts from the email or converting the message 
to text only; 


o encrypting the body with the Recipient’s key using PGP (Pretty 
Good Privacy) or S/MIME; 
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o enforcing community standards by rewriting banned words; and 


o allowing moderators to add arbitrary commentary to messages 
(discussed in [RFC6377]). 


Any such modifications would invalidate a DKIM signature. 


Header and content modifications are common for many Mailing Lists 
and are often central to present Mailing List functionality and 
usage. Furthermore, MUAs have come to rely on Mailing List message 
modifications to present messages to end users in expected ways. 


3.2.3.1. Mailing List Operational Effects 


Mailing Lists may also have the following DMARC interoperability 
issues: 


o Subscribed members may not receive email from members that post 
using domains that publish a DMARC "p=reject" policy. 


o Mailing Lists may interpret DMARC-related email rejections as an 
inability to deliver email to the Recipients that are checking and 
enforcing DMARC policy. This processing may cause subscribers 
that are checking and enforcing DMARC policy to be inadvertently 
suspended or removed from the Mailing List. 


3.2.4. Gateways 


A Gateway performs the basic routing and transfer work of message 
relaying, but it is also permitted to modify content, structure, 
addressing, and/or other attributes as needed to send the message 
into a messaging environment that operates under different standards 
or potentially incompatible policies. 


Gateways share the same DMARC interoperability issues as ReSenders 
(Section 3.2.2). 


Gateways may also share the same DMARC interoperability issues as 
MTAs (Section 3.1.2). 


Receiver systems on the non-SMTP side of a protocol Gateway may be 
unable to evaluate DKIM and SPF. If a message passes through a 
second protocol Gateway back into the SMTP domain, the 
transformations commonly break the original DKIM signature(s). 


Gateway-level forwarding can introduce DMARC interoperability issues 


if the Gateway is configured to rewrite the message into alternate 
receiving domains. For example, an acquisition may lead an acquiring 
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company to decide to decommission the acquired company’s domains by 
rewriting messages to use the domain of the acquiring company. Since 
the RFC5322.To header field is usually DKIM-signed, this kind of 
rewriting will invalidate such DKIM signatures. 


3.2.5. Boundary Filters 


To enforce security boundaries, organizations can subject messages to 
analysis for conformance with their safety policies. A filter might 
alter the content to render it safe, such as by removing or otherwise 
altering content deemed unacceptable. 


Boundary Filters share the same DMARC interoperability issues as 
ReSenders. 


Issues may arise with SPF and DKIM evaluation if performed after 
filter modifications. 


Examples of Boundary Filters include: 


o Malware scanning: To protect readers and its reputation, an MTA 
that transfers a message may remove content believed to be harmful 
from messages, reformulate content to canonical formats in order 
to make them more trustworthy or easier to scan, and/or add text 
in the body to indicate the message has been scanned. Any such 
modifications would invalidate a DKIM signature. 


o Spam filtering: To protect its reputation and assist other MTAs, 
an MTA may modify a message to indicate its decision that the 
message is likely to be unwanted and/or add text in the body to 
indicate that such filtering has been done. 


o Other text additions: An MTA may add an organizational disclaimer 
or advertisement, for instance. 


o URL alteration: Some systems will rewrite or alter embedded URLs 
as a way to control the potential threat from malware. 


o Secondary MX services: The secondary MX for an organization may be 
external to the normal mail processing for the organization, and 
it may queue and forward to the primary when it becomes available. 
This will not invalidate DKIM but will prevent the primary from 


validating SPF normally. In this case, however, it is 
inappropriate for a primary MX server to perform an SPF check 
against its own secondaries. Rather, the secondary MX should 


perform this function and employ some trusted mechanism to 
communicate the results of the SPF, DKIM, and DMARC evaluation(s) 
to the primary MX server. 
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3.3. Combinations 


Indirect email flows can be combined. For example, a university 
student may subscribe to a Mailing List (using his university email 
address) while this university email address is configured to forward 
all emails to a freemail or a post-education corporate account 
provider where a more permanent email address for this student 
exists. 


Within an organization, the message may pass through various MTAs 
(Section 3.1.2), each of which performs a different function 
(authentication, filtering, distribution, etc.). 


4. Possible Mitigations of Interoperability Issues 


Solutions to interoperability issues between DMARC and indirect email 
flows vary widely in their scope and implications. They range from 
improvements to underlying processing, such as proper handling of 
multiple DKIM signatures, to more radical changes to the messaging 
architecture. This section describes possible ways to address 
interoperability issues. Note that these particular mechanisms may 
not be considered "best practices" and may, in some cases, violate 
various conventions or expectations. 


Receivers sometimes need to deliver email messages that do not 
conform to any standard or protocol, but are otherwise desired by end 
users. Mitigating the impact of DMARC on indirect email flows is 
especially important to receivers that operate services where ease of 
use and compatibility with existing email flows is a priority. 


DMARC provides a mechanism (local policy) for receivers to make 
decisions about identity alignment acceptability based on information 
outside DMARC and communicate those decisions as "overrides" to the 
sender. This facility can be used to ease some interoperability 
issues, although care is needed to ensure that this does not create 
loopholes for abuse. 


To further complicate the usage of mitigations, mitigation may not be 
desired if the email in question is of a certain category of high 
value or high risk (security-related) transactional messages (dealing 
with financial transactions or medical records, for example). In 
these cases, mitigating the impact of DMARC due to indirect email 
flows may not be desirable (counterproductive or allowing for abuse). 


As a final note, mail systems are diverse and widely deployed. 
Systems of various ages and capabilities are expected to preserve 
interoperability with the rest of the SMTP ecosystem. For instance, 
Qmail is still used, although the base code has not been updated 
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since 1998. ezmlm, a once popular MLM, is still deployed but has not 
been updated since 1997, although a new version (ezmlm-idx) exists. 
Old versions of other open- and closed-source MTAs are still commonly 
in operation. When dealing with aging or unsupported systems, some 
solutions may be time-consuming and/or disruptive to implement. 


4.1. Mitigations in Current Use 


Because DMARC is already widely deployed, many operators already have 


mitigations in use. These mitigations vary in their effectiveness 
and side effects but have the advantage that they are currently 
available. 


4.1.1. Mitigations for Senders 
4.1.1.1. Identifier Alignment 


o MTAs handling multiple domains may choose to change 
RFC5321.MailFrom to align with RFC5322.From to improve SPF 
usability for DMARC. 


o MTAs handling multiple domains may also choose to align 
RFC5321.HELO/.EHLO to RFC5322.From, particularly when sending 
notification messages. Dynamically adjusting the 
RFC5321.HELO/.EHLO based on the RFC5322.From may not be possible 
for some MTA software. 


o MTAs may choose to DKIM-sign notification messages with an aligned 
domain to allow a DKIM-based DMARC pass. 


o MTAs sending email on behalf of multiple domains may require 
Domain Owners to provide DKIM keys to use DKIM to avoid SPF 
validation issues, given the requirement for DMARC alignment with 
the RFC5322.From header field. Managing DKIM keys with a third 
party has security risks that should be carefully managed (see 
also [RFC6376], Section 8). Methods involving CNAMEs and/or 
subdomains may alleviate some risks. 


o Senders who are sending on behalf of users in other administrative 
domains may choose to use an RFC5322.From under the sender’s 
control. The new From can be either a forwarding address ina 
domain controlled by the Sender or a placeholder address, with the 
original user’s address in an RFC5322.Reply-to header field. 
However, performing this modification may cause the Recipient’s 
MUA to deviate from customary behavior. 


Martin, et al. Informational [Page 16] 


RFC 7960 DMARC Indirect Email Interop Issues September 2016 


When implementing "forward-to-friend" functionality, one approach 
to avoid DMARC failures is to pass a well-formed message to the 
user’s MUA so that it may fill in an appropriate identity and 
submit through its own MSA. 


Senders can use domains with distinct DMARC policies for email 
sent directly and email known to use indirect mail flows. 

However, for most well-known brands, all active domains are likely 
to be targeted equally by abusers. 


-2. Message Modification 


Senders can maximize survivability of DKIM signatures by limiting 
the header fields they sign and using relaxed canonicalization. 
Using the DKIM length tag to allow appended signatures is 
discouraged due to the security risk created by allowing arbitrary 
content to be appended to legitimate email. 


Senders can also maximize survivability by starting with RFC- 
compliant headers and common body formats. 


In order to minimize transport-—based conversions, Senders can 
convert messages to a lowest denominator MIME content-transfer 
encoding such as quoted-printable or base64 before signing 
([RFC6376], Section 5.3). 


Mitigations for Receivers 


-l. Identifier Alignment 


Receivers should update DKIM handling libraries to ensure that 
they process all valid DKIM signatures and check each signature 
for alignment. 


-2. Policy Override 


Receivers can amalgamate data from their user base to create lists 
of forwarders and use such lists to inform DMARC local policy 
overrides. This process may be easier for large receivers where 
data and resources to create such lists are more readily available 
than at smaller sites, where there are fewer accounts that receive 
forwarded mail and other resources may be scarce. 
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4.1.3. Mitigations for ReSenders 
4.1.3.1. Changes to the RFC5322.From 


Many ReSender issues can be avoided by using an RFC5322.From header 
field under the ReSender’s control, instead of the initial 
RFC5322.From. This will correct Identifier Alignment issues and 
allow arbitrary message modification as long as the ReSender signs 
the message with an aligned domain signature. When ReSenders change 
the RFC5322.From, it is desirable to preserve the information about 
the original initiator of the message. 


A first option is to use the Original-From [RFC5703] (or X-Original- 
From) header field for this purpose in various contexts (X- header 
field names are discouraged by [RFC6648]). However, handling of 
Original-From (or X-Original-From) is not defined anywhere. It is 
not currently used consistently or displayed to the user, and in any 
situation where it is used, it is a new unauthenticated identifier 
available for exploitation unless included within the scope of the 
new DKIM signature(s). 


Another option for ReSenders is to rewrite the RFC5322.From header 
field address to a locally controlled address that will be forwarded 
back to the original sender (subject to its own ReSender forwarding 
mitigations). 


4.1.3.2. Avoiding Message Modification 


o Forwarders can choose to add email header fields instead of 
modifying existing headers or bodies, for instance, to indicate a 
message may be spam. 


o Forwarders can minimize the circumstances in which they choose to 
fix messages, preferring to preserve non-compliant headers to 
creating DKIM failures. 


o Forwarders can choose to reject messages with suspect or harmful 
content instead of modifying them. 


4.1.3.3. Mailing Lists 
[RFC6377] provides some guidance on using DKIM with Mailing lists. 
The following mitigation techniques can be used to ease 
interoperability issues with DMARC and Mailing lists: 
o Configuring the Mailing List Manager (MLM) to alter the 


RFC5322.From header field to use the domain of the MLM is a 
mitigation policy that is now present in several different Mailing 
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List software distributions. Since most list subscribers prefer 
to know the identity of the Author of the original message, 
typically this information may be provided in the display name 
part of the RFC5322.From header field. This display name needs to 
be carefully crafted so as to not collide with the original 
display name of the Author, nor contain something that looks like 
an email address or domain name. These modifications may to some 
extent defeat the purpose of DMARC itself. It may make it 
difficult to ensure that users of all email clients can easily 
reply to the Author, the list, or all using the email client 
features provided for that purpose. Use of the RFC5322.Reply-To 
header field can alleviate this problem depending on whether the 
Mailing List is configured to reply-to-list, reply-to-author, or 
reply-to-fixed-address; however, it is important to note that this 
header field can take multiple email addresses. When altering the 
RFC5322.From, there are three possibilities: 


1. change it to put the Mailing List email address, 


2. change it to a locally defined address that will be forwarded 
back to the original sender, or 


3. "break" the address by modifying the domain to a non-existent 
domain (such as by adding a suffix like ".invalid"). 


The latter modification may create issues because it is an invalid 
domain name, and some MTAs may pay particular attention to the 
validity of email addresses in RFC5322.From and the reputation of 
the domains present there. 


o Configuring the MLM to "wrap" the message in a MIME message/rfc822 
part and to send as the Mailing List email address. Many email 
clients (as of the publication of this document), especially 
mobile clients, have difficulty reading such messages, and this is 
not expected to change soon. 


o Configuring the MLM to not modify the message so that the DKIM 
signature remains valid. Some Mailing Lists are set up this way 
and require few additional changes to ensure the DKIM signature is 
preserved. Moving lists that currently modify mail to a policy 
like this may be too much of a change for the members of such 
lists. 


o Rejecting posts or membership requests from domains with a DMARC 


policy other than "p=none". However, members or potential members 
of such Mailing Lists may complain of unfair exclusion. 
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o To alleviate unsubscribes to the Mailing List due to the messages 
bouncing because of DMARC, the MLM needs to not act on 
notification messages due to message authentication issues. 
[RFC3463] specifies Enhanced Mail System Status Codes, which help 
differentiate between various failure conditions. Correctly 
interpreting Extended SMTP error messages is useful in this case. 
In particular, extended status codes for SPF and DKIM causes are 
defined in [RFC7372], and DMARC-related failure indications are 
discussed in DMARC ([RFC7489], Section 10.3). 


All these techniques may provide some specific challenges to MUAs and 
different operational usages for end users (like rewriting filters to 
sort emails in folders). There will be some time before all 
implications are understood and accommodated. 


4.2. Proposed and In-Progress Mitigations 


The following mitigations are based on Internet-Drafts (I-Ds) that 


are still in process. They are described here to offer an 
exploratory path for solutions. These solutions should not be used 
in a production environment. Because of the transient nature of 


I-Ds, specific citations are not included because a number of them 
will inevitably become obsolete, and those that gain consensus in the 
community will become RFCs and should be discovered as such. 


o Third-party authorization schemes provide ways to extend 
Identifier Alignment under control of the Domain Owner. 


o Ways to canonicalize messages that transit Mailing Lists so that 
their alterations can be isolated from the original signed 
content. 


o Mechanisms to record message transformations applied at each hop 
so they can be reversed and the original signed content recovered. 


o "Conditional" DKIM signatures, whereby the Author domain indicates 
its signature is only good if accompanied by a signature from an 
expected downstream relay. 


o Mechanisms to extend Authentication-Results [RFC7601] to multiple 


hops, creating a provable chain of custody as well as a view of 
message authentication results at each handling step. 
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4.2.1. Getting More Radical: Requiring New Communication Paths between 
MUAS 


In practice, a number of operators are using strict alignment mode in 
DMARC in order to avoid receiving new and innovative forms of 
unwanted and unauthentic email through systems purporting to be 
Mailing List handlers. The receiving ADMD has no knowledge of which 
lists the user has subscribed to and which they have not. One avenue 
of exploration would be for the user to authorize Mailing Lists as 
proxies for authentication, at which point the receiving ADMD would 
be vesting some trust in the Mailing List service. The creators of 
DKIM foresaw precisely this possibility at the time by not tightly 
binding any semantics to the RFC5322.From header field. Some 
experimental work has taken place in this area, as mentioned above. 
Additional work might examine a new communication path to the user to 
authorize some form of transitive trust. 


5. Security Considerations 


This document is an analysis of DMARC’s impact on indirect email 


flows. It describes the possibility of accidental denial of service 
that can be created by rejections of messages by DMARC-aware mail 
receivers. 


Section 4.1.1.1 discusses the importance of appropriate DKIM key 
management vis-a-vis third-party email senders. 


Section 4.1.3.3 warns that rewriting the RFC5322.From header field to 
create an artificial domain name should not be done with any domain. 
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Appendix A. Example SPF Bounce 
This example illustrates a notification message "bounce". 
A.1. Initial Message 
Here is the message as it exits the Origin MTA (segv.dl.example): 


Return-Path: <jqd@dl.example> 

Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 
(authenticated bits=0) 
by segv.dl.example with ESMTP id tOFN4a80084569; 

Thu, 14 Jan 2015 15:00:01 -0800 (PST) 

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dl.example; 
S=20130426; t=1421363082; 
bh=EoJqaaRvhrngQxmO3VnRIIMRBgecukflpdkxt fGyWaU=; 
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-—Type: 

Content-Transfer-Encoding; 
b=HxsvPubDE+R96v9dM9Y 7V3dJUXva jd6rvF 5ec5BPe/vpVBRUnD4I2weElyYijrvow 
bv 9uUA1t 94kKMNOO+haFo6hiOPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJ1 
gotsX4RkbNcUh1 fnoQ0pt+CywwWjiel 8aRb6eof 6WDO= 

Message-ID: <54B84785.1060301@d1.example> 

Date: Thu, 14 Jan 2015 15:00:01 -0800 

From: John Q Doe <jqd@d1.example> 

To: no-recipient@dmarc.org 

Subject: Example 1 


Hey gang, 
This is a test message. 
piel 
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A.2. Notification Message 


When dmarc.org rejects the message without a DKIM signature, it 
specifies the RFC5321.HELO/.EHLO domain as dmarc.org.local, which has 
no SPF record. dmarc.org has a reject policy in place for such non- 
passing cases. Since there is no DKIM signature on the notification 
message, the failed SPF lookup results in a dmarc=fail, and 
dl.example could be expected to discard the notification message 
itself: 


Return-Path: <> 
Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1]) 
by mx.dl.example with ESMTPS id Lkm253023jJR5 
for <jqd@dl.example> 
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128) ; 
Thu, 14 Jan 2015 15:00:24 -0800 (PST) 
Authentication-Results: mx.dl.example; 
spf=none (dl.example: dmarc.org.local does not designate 
permitted sender hosts) smtp.mail=; 
dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org 
MIME-Version: 1.0 
Received: from segv.dl.example (segv.dl.example [198.51.100.1]) 
by 192.0.2.2 with SMTP id u67mr102828634qge33; Thu, 
14 Jan 2015 15:00:24 -0800 (PST) 
From: Mail Delivery Subsystem <mailer-daemon@dmarc.org> 
To: jqd@d1l.example 
Subject: Delivery Status Notification (Failure) 
Message-ID: <001lallcl6e6a9ead220528df294a@dmarc.org> 
Date: Thu, 14 Jan 2016 23:00:24 +0000 
Content-Type: text/plain; charset=UTF-8 


This is an automatically generated Delivery Status Notification 


Delivery to the following recipient failed permanently: 
no-recipient@dmarc.org 


Technical details of permanent failure: 
Your message was rejected by the server for the recipient domain 
dmarc.org by mail.dmarc.org [192.0.2.1]. 


The error that the other server returned was: 
550 5.1.1 <no-recipient@dmarc.org>... User unknown 


Soa Original message ----- 

Return-Path: <jqd@dl.example> 

Received: from [203.252.0.131] (131-0-252-203-dsl.static.example.com 
[203.252.0.131]) (authenticated bits=0) 
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by segv.dl.example with ESMTP id tOFN4a80084569; 
Thu, 14 Jan 2015 15:00:01 -0800 (PST) 
(envelope-from jqd@dl.example) 

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dl.example; 
S=20130426; t=1421363082; 
bh=EoJqaaRvhrngQxmO3VnRIIMRBgecukflpdkxt fGyWaU=; 
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 

Content-Transfer-Encoding; 
b=HxsvPubDE+R96v9dM9Y 7V3dJUXva jd6rvF 5ec5BPe/vpVBRUnD4I2weElyYijrvow 
bv9uUA1t 94kKMNOO+haFo6hiOPnkuDxku5t+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJ1 
gotsX4RkbNcUh1 fnoQ0p+CywwWjiel8aRb6eof 6WDO= 

Message-ID: <54B84785.1060301@d1.example> 

Date: Thu, 14 Jan 2015 15:00:01 -0800 

From: John Q Doe <jqd@d1.example> 

To: no-recipient@dmarc.org 

Subject: Example 1 


Hey gang, 
This is a test message. 
Hos 
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